Add x86_64-linux-kernel target #64051

alex · 2019-09-01T02:49:49Z

This adds a target specification for Linux kernel modules on x86_64, as well as base code that can be shared with other architectures.

I wasn't totally sure about what the best name for this was.

There's one open question on whether we should use the LLVM generic x86_64-elf target, or the same one used for the Linux userspace.

r? @joshtriplett

This adds a target specification for Linux kernel modules on x86_64, as well as base code that can be shared with other architectures.

alex · 2019-09-01T02:57:41Z

The failing mingw-check build doesn't seem related at all.

rust-highfive · 2019-09-01T04:52:55Z

The job mingw-check of your PR failed (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

2019-09-01T02:50:26.2561895Z ##[command]git remote add origin https://github.com/rust-lang/rust
2019-09-01T02:50:26.8027751Z ##[command]git config gc.auto 0
2019-09-01T02:50:26.8032716Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2019-09-01T02:50:26.8037694Z ##[command]git config --get-all http.proxy
2019-09-01T02:50:26.8040304Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/64051/merge:refs/remotes/pull/64051/merge

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

joshtriplett · 2019-09-01T14:33:45Z

Looks great to me!

@bors r+

bors · 2019-09-01T14:33:46Z

📌 Commit 5e933b4 has been approved by joshtriplett

alex · 2019-09-01T14:34:47Z

@joshtriplett Thanks much! If we wanted to move this to tier 2, providing pre-compiled libcore, what's involved in doing that? Just hacking on the build scripts?

bors · 2019-09-01T15:29:01Z

⌛ Testing commit 5e933b4 with merge 3d879bbc55e6515a201fac7a78a2dbeee5f38a9f...

bors · 2019-09-01T17:57:26Z

💔 Test failed - checks-azure

rust-highfive · 2019-09-01T17:57:27Z

The job x86_64-gnu-aux of your PR failed (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

alex · 2019-09-01T19:02:31Z

Test appears to have failed with:

 Downloading crates ...
  Downloaded lazy_static v0.2.5
  Downloaded conduit-mime-types v0.7.3
error: failed to download from `https://crates.io/api/v1/crates/log/0.3.7/download`

Caused by:
  [35] SSL connect error (error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure)
thread 'main' panicked at 'tests failed for https://github.com/iron/iron', src/tools/cargotest/main.rs:86:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

which seems unrelated?

joshtriplett · 2019-09-01T20:03:38Z

Yeah, that does look entirely unrelated.

@bors retry

bors · 2019-09-02T09:11:45Z

⌛ Testing commit 5e933b4 with merge 9b0a099c274d69bd9cb1cbbd7a967fe28c3a77d1...

mati865 · 2019-09-02T09:37:59Z

Is there a way we can control the use of PIE at build time using stable Rust options?

AFAIK Rust libs have to be compiled with the same PIE config as the resulting binary making xargo necessary.

rust-highfive · 2019-09-02T11:28:44Z

The job x86_64-gnu-aux of your PR failed (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

bors · 2019-09-02T11:29:00Z

💔 Test failed - checks-azure

alex · 2019-09-02T12:54:14Z

Another SSL error.

alex · 2019-09-04T00:41:02Z

@joshtriplett I think this can safely be retry'd

joshtriplett · 2019-09-04T00:52:38Z

@bors retry

@joshtriplett

…joshtriplett Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64, as well as base code that can be shared with other architectures. I wasn't totally sure about what the best name for this was. There's one open question on whether we should use the LLVM generic x86_64-elf target, or the same one used for the Linux userspace. r? @joshtriplett

@joshtriplett

…joshtriplett Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64, as well as base code that can be shared with other architectures. I wasn't totally sure about what the best name for this was. There's one open question on whether we should use the LLVM generic x86_64-elf target, or the same one used for the Linux userspace. r? @joshtriplett

@joshtriplett

…joshtriplett Add x86_64-linux-kernel target This adds a target specification for Linux kernel modules on x86_64, as well as base code that can be shared with other architectures. I wasn't totally sure about what the best name for this was. There's one open question on whether we should use the LLVM generic x86_64-elf target, or the same one used for the Linux userspace. r? @joshtriplett

@ghost

Rollup of 11 pull requests Successful merges: - #62848 (Use unicode-xid crate instead of libcore) - #63774 (Fix `window.hashchange is not a function`) - #63930 (Account for doc comments coming from proc macros without spans) - #64003 (place: Passing `align` = `layout.align.abi`, when also passing `layout`) - #64030 (Fix unlock ordering in SGX synchronization primitives) - #64041 (use TokenStream rather than &[TokenTree] for built-in macros) - #64051 (Add x86_64-linux-kernel target) - #64063 (Fix const_err with `-(-0.0)`) - #64083 (Point at appropriate arm on type error on if/else/match with one non-! arm) - #64100 (Fix const eval bug breaking run-pass tests in Miri) - #64157 (Opaque type locations in error message for clarity.) Failed merges: r? @ghost

- aarch64-unknown-none: rust-lang/rust#68334 - aarch64-unknown-none-softfloat: rust-lang/rust#64589 - armv7-unknown-linux-gnueabi: rust-lang/rust#63107 - armv7-unknown-linux-musleabi: rust-lang/rust#63107 - aarch64-apple-tvos: rust-lang/rust#68191 - armv7a-none-eabihf: rust-lang/rust#68253 - i686-unknown-uefi: rust-lang/rust#64334 - thumbv7neon-unknown-linux-musleabihf: rust-lang/rust#66103 - x86_64-apple-ios-macabi: rust-lang/rust#63467 - x86_64-apple-tvos: rust-lang/rust#68191 - x86_64-linux-kernel: rust-lang/rust#64051 - x86_64-unknown-hermit-kernel: rust-lang/rust#66713 - x86_64-unknown-illumos: rust-lang/rust#71145 Moved to tier 2: - aarch64-unknown-none: rust-lang/rust#68334

Ericson2314 · 2020-10-11T20:27:13Z

I was pointed to #74247, a better place to bring this up.

Sorry I'm late to the party, but is x86_64-linux-kernel something made up for Linux with Rust, or a preexisting convention? If it is new, I would strongly prefer that it be changed.

The triples/configs/whatever are a mess, but so far mentioning some OS has meant "I am running on that OS" i.e. "I have a interface[1] for communicating with that kernel and I am one of its processes". But Kernel code doesn't talk to the kernel via syscalls, and thus violates that assumption.

Perhaps #[cfg(target_os = "linux")] has been patched to be false for this, but other tools besides rust also deal with this triples, and this would require a new special case everywhere to handle, which is a big maintenance burden.

Something like x86_64-unknown-linuxkernel or even x86_64-unknown-none (the kernel is a baremetal program, after all) would be far, far preferable.

[1] Whether the direct syscall ABI is stable, like Linux or a canonical libc is, like FreeBSD, is a separate distinction to the point I'm making. Regardless of what's stabilized internal kernel interfaces are very different than the interfaces for hosted processes.

alex · 2020-10-11T20:32:42Z

It was invented for Rust. I don't have a strong opinion on the correct convention, and I'm more than happy to do whatever the Rust devs think is best.

…

On Sun, Oct 11, 2020 at 4:27 PM John Ericson ***@***.***> wrote: Sorry I'm late to the party, but is x86_64-linux-kernel something made up for Linux with Rust, or a preexisting convention? If it is new, I would *strongly* prefer that it be changed. The triples/configs/whatever are a mess, but so far mentioning some OS has meant "I am running on that OS" i.e. "I have a interface[1] for communicating with that kernel and I am one of its processes". But Kernel code does talk to the kernel via syscalls, and thus *violates* that assumption. Perhaps #[cfg(target_os = "linux")] has been patched to be false for this, but other tools besides rust also deal with this triples, and this would require a new special case everywhere to handle, which is a big maintenance burden. Something like x86_64-unknown-linuxkernel or even x86_64-unknown-none (the kernel is a baremetal program, after all) would be far, far preferable. [1] Whether the direct syscall ABI is stable, like Linux or a canonical libc is, like FreeBSD, is a separate distinction to the point I'm making. Regardless of what's stabilized internal kernel interfaces are very different than the interfaces for hosted processes. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#64051 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBE5B3OTVEI7YKEWPVLSKIIK3ANCNFSM4ISVMTRA> .

-- All that is necessary for evil to succeed is for good people to do nothing.

Add x86_64-linux-kernel target

5e933b4

This adds a target specification for Linux kernel modules on x86_64, as well as base code that can be shared with other architectures.

rust-highfive assigned joshtriplett Sep 1, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 1, 2019

alex mentioned this pull request Sep 1, 2019

Upstream target to Rust for these fishinabarrel/linux-kernel-module-rust#155

Closed

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 1, 2019

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 1, 2019

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 1, 2019

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 2, 2019

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 4, 2019

Centril mentioned this pull request Sep 5, 2019

Rollup of 11 pull requests #64164

Closed

Centril mentioned this pull request Sep 5, 2019

Rollup of 11 pull requests #64168

Closed

Centril mentioned this pull request Sep 5, 2019

Rollup of 11 pull requests #64172

Merged

bors merged commit 5e933b4 into rust-lang:master Sep 5, 2019

alex deleted the linux-kernel-module-target branch September 5, 2019 16:42

geofft mentioned this pull request Sep 7, 2019

Use target from rust itself fishinabarrel/linux-kernel-module-rust#172

Merged

ehuss mentioned this pull request May 15, 2020

Update platform tiers. rust-lang/rust-forge#356

Merged

Ericson2314 mentioned this pull request Oct 11, 2020

consider disallowing setting target_family if target_os=none #74247

Open

bstrie mentioned this pull request Mar 23, 2022

Promote x86_64-unknown-none to Tier 2 rust-lang/compiler-team#499

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add x86_64-linux-kernel target #64051

Add x86_64-linux-kernel target #64051

alex commented Sep 1, 2019

alex commented Sep 1, 2019

rust-highfive commented Sep 1, 2019

joshtriplett commented Sep 1, 2019

bors commented Sep 1, 2019

alex commented Sep 1, 2019

bors commented Sep 1, 2019

bors commented Sep 1, 2019

rust-highfive commented Sep 1, 2019

alex commented Sep 1, 2019

joshtriplett commented Sep 1, 2019

bors commented Sep 2, 2019

mati865 commented Sep 2, 2019

rust-highfive commented Sep 2, 2019

bors commented Sep 2, 2019

alex commented Sep 2, 2019

alex commented Sep 4, 2019

joshtriplett commented Sep 4, 2019

Ericson2314 commented Oct 11, 2020 •

edited

Loading

alex commented Oct 11, 2020 via email

Add x86_64-linux-kernel target #64051

Add x86_64-linux-kernel target #64051

Conversation

alex commented Sep 1, 2019

alex commented Sep 1, 2019

rust-highfive commented Sep 1, 2019

joshtriplett commented Sep 1, 2019

bors commented Sep 1, 2019

alex commented Sep 1, 2019

bors commented Sep 1, 2019

bors commented Sep 1, 2019

rust-highfive commented Sep 1, 2019

alex commented Sep 1, 2019

joshtriplett commented Sep 1, 2019

bors commented Sep 2, 2019

mati865 commented Sep 2, 2019

rust-highfive commented Sep 2, 2019

bors commented Sep 2, 2019

alex commented Sep 2, 2019

alex commented Sep 4, 2019

joshtriplett commented Sep 4, 2019

Ericson2314 commented Oct 11, 2020 • edited Loading

alex commented Oct 11, 2020 via email

Ericson2314 commented Oct 11, 2020 •

edited

Loading